home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 802 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.1 KB

  1. Path: engnews1.Eng.Sun.COM!taumet!clamage
  2. From: "Eugene Radchenko" <eugene@qsar.chem.msu.su>
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Anyone considered inheritable friendship?
  5. Date: 21 Mar 1996 16:29:08 GMT
  6. Organization: Lab. of Org.Synth., MSU
  7. Approved: clamage@eng.sun.com (comp.std.c++)
  8. Message-ID: <AIQ5MKn8N7@qsar.chem.msu.su>
  9. References: <3149AC2A.42D2@bis.adp.com>
  10. NNTP-Posting-Host: taumet.eng.sun.com
  11. X-Mailer: dMail [Demos Mail for DOS v1.23]
  12. Content-Length: 2257
  13. X-Lines: 46
  14. Originator: clamage@taumet
  15.  
  16. Russell Gold <goldr@inet.bis.adp.com> writes
  17. >> But it is not. Inheritable friendship is a natural extension of
  18. >> normal friendship (for tightly coupled classes) to tightly
  19. >> coupled hierarchies.
  20. >
  21. >Except that hierarchies are necessarily open, so making a
  22. >hierarchy a friend means that the original class becomes open to
  23. >classes which were never imagined by its author.  You can never
  24. >guarantee that a "tightly coupled hierarchy" will remain tightly
  25. >coupled.  AFAIK there is no prohibition on making multiple members
  26. >of the same hierarchy friends to the same class.  Doing this allows
  27. >the original author to restrict access to only those members of the
  28. >hierarchy which should have that access.
  29.  
  30. Why is everybody so obsessed with friend security? They are not for this
  31. (read Strojstroup [sp?]).
  32.  
  33. >> In my project (that spawned the question) base class builds a
  34. >> certain graph and derived classes decompose it in different ways
  35. >> using helper objects
  36. >> from other hierarchies. Nobody except those objects (and original
  37. >> object tree, of course) has any business to that graph.
  38. >
  39. >So make each of those classes friends of the graph.
  40. But this implies that we must have a closed list of all helper objects
  41. which breaks the design (I want to be able to easily snap together
  42. different approaches/algorithms -- evev if they are in different DLLs).
  43. Similarly, in iostreams/streambufs trees, are you saying that each
  44. streambuf must have a complete list of all streams?
  45.  
  46. >OR, you can use a little trick within the confines of the language.
  47. [....]
  48. Which is not very neat, IMHO...
  49.  
  50.             Bye                            Genie
  51. --
  52. -----------------------------------------------------------------------
  53. Eugene V. Radchenko              Research associate, Computer Chemistry
  54. E-mail: eugene@qsar.chem.msu.su                   Fax: +7-(095)939-0290 
  55. Ordinary mail:     Chair of Organic Chemistry, Department of Chemistry,
  56.                          Moscow State University, 119899 Moscow, Russia
  57. -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
  58.  I don't think anyone on the C++ standards committee believes that all
  59.  C++ programs should be strictly conforming.
  60.                            Fergus Henderson, moderator of comp.std.c++
  61.  
  62.  
  63.  
  64. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  65. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  66. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  67. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  68. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  69.